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Abstract of FR2777673 

The invention concerns a chip card (21) 
comprising data processing means and main 
data storage means, wherein the processing 
means inciude: means for detecting, while the 
chip card is operating, that the main storage 
means contain an amount of data such that an 
operation cannot be executed; means for 
selecting, in the main storage means, a-set-of 
data to be unloaded (K). whereof the unloading 
can release in the main storage means a space 
sufficient for executing said operation; means for 
unloading the set of data to be unloaded (K) into 
secondary storage means (23 to 25), in the event 
said secondary storage means do not contain 
said data set to be unloaded. The invention also 
concerns the associated communication method 
and protocol. 
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^ DISPOSITIF DE TRAITEMENT DE L IN FORMATION COWIPRENANT DES MOYENS POUR GERER UNE 
MEMOIRE VIRTUELLE. ET PROCEDE DE STOCKAGE D'INFORMATIONS ASSOCIE. 

@) L'Invention conceme un dispositif de traitement de I'in- 
formation (20, 22) comprenant des moyens de traitement et 
des moyens de m6morisation principaux, caract6ris6 en ce 
qu'il comprend: 

- des moyens pour d6tecter que les moyens de memori- 
sation principaux contiennent une quantity dMnformations 
telle qu'un stockage suppl^mentaire d'un ensemble donn6 
tf informations k stocker (J) n'est pas possible; 

- des moyens pour s6lectionner. dans les moyens de 
memorisation principaux, un ensennble d'informations k de- 
charger (K) pour liberer dans les moyens de memorisation 
principaux un espace autorisant le stockage dudit ensemble 
d'informations ^ stocker; 

- des moyens pour decharger Tensemble d'informations 
^ decharger (K) dans des moyens de memorisation secon- 
daires (23 k 25), dans le cas ou ces moyens ne contiennent 
pas ledit ensemble d'informations ^ decharger; et 

- des moyens pour stocker dans les moyens de memo- 
risation principaux {'ensemble d'informations & stocker (J). 

L'invention concerne aussi le precede assode. 




Titre : 

Dispositif de traitement de rinformation comprenant des moyens pour g6rer 
une m§moire virtual le, et procddd de stockage d' informations associd 

5 La prdsente invention conceme un dispositif de traitement de 

rinformation presentant une memoire de taille limit^e, et agenc6 en 
consequence pour effectuer une gestion optimale de cette mSmoire. Elle 
conceme done en particulier la carte ^ microprocesseur ou Equivalent. 

10 Depuis une vingtaine d'annde, ce type de cartes prend une 

grande place dans la vie courante. Le domaine bancaire s'est int^ressd te 
premier aux cartes k microcircuit : leur principal avantage est de diminuer la 
fraude. Les socidtSs de tEI6vision d peage et de radiotelSphonie les utilisent 
comme moyen de g6n6ration des cl6s qui servent S chiffrer et d^chiffrer des 

15 Emissions cryptEes. Pour garantir la sEcuritE, il a fallu crEer une nouvelle 
architecture de circuit integrd. Les cartes de type porte-monnaie 
6lectronique contiennent une somme d'argent 6lectronique ; d'autres cartes, 
dites de fidElitE. procurent des avantages financiers a leurs propriEtaires. 

20 On le voit, les appareils en relation avec des cartes d microcircuit 

et plus particullErement les cartes a microprocesseur, sont utilisables dans 
un nombre de plus en plus grand d'applications. Au debut, le systdme 
d'exploitation des cartes, c'est a dire le programme situE en mEmoire ROM, 
ne pouvait gerer qu'une seule application. Le systeme d'exploitation est 

25 inscrit au moment de la fabrication du micro-circuit. En augmentant la taille 
de la m6moire programme (ROM) et de la memoire programmable non 
volatile (EPROM et EEPROM, de nos jours FeRAM). le systdme 
d'exploitation peut exEcuter davantage de fonctions. Mais le nombre de ces 
fonctions est toujours limits par la taille de la mEmoire ROM. De plus, le 

30 rajout d'une fonction supplEmentaire dans la ROM implique de rEaliser un 
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nouv au masque ; cette realisation coute tres cher et n'est v^ritablement 
rentabilis6e que si une grande quantit6 de cartes sont concem6es. 

Un moyen d'augmenter le nombre de ces fonctions sans toucher 
5 d la m^moire ROM consiste d ^ire dans la m6moire programmable, du 
programme executable ainsi que des donn6es permettant de le faire 
fonctionner: II est ainsi possible de rajouter des fonctions suppl6mentaires d 
un systeme d'exploitation qui ne poss6de au depart qu'un nombre figd de 
fonctions. La demande de brevet FR-A-2.748.134 d6crit un moyen de 
10 charger du programme dans la m6moire programmable. Mais la m6moire 
programmable est d'une taille Iimit6e : une fois remplie avec un programme, 
il n'est plus possible de rajouter de fonctions. De plus, le stockage de ce 
programme s'effectue au detriment de la place m6moire destin6e aux 
donn6es dans la m6moire programmable. Le pr6c6dent proc§d6 s'utilise 
1 5 pour corriger certaines imperfections du programme situ6 en ROM ou pour 
rajouter quelques autres fonctions. Si une carte doit ex6cuter un programme 
d'une taille tr6s importante. le proc6d6 d§crit dans ce document peut 
s'averer insuffisant. 

20 La presente invention a pour objet de r6soudre ce probleme en 

proposant une methode de chargement et dechargement de la m6moire 
programmable en fonction des besoins en ce qui conceme les programmes 
et/ou les donn6es applicatives. pour un dispositif de traitement de 
I'information dont la m6moire est de taille Iimit6e. comme par exemple celle 

25 d'une carte. Ainsi dans le cas de la carte, il deviant possible d celle-ci 
d'executer des applications trte diverses telles que : Porte-Monnaie 
Electronique. application bancaire, teiephonie GSM ou application sant6 
actuellement exp6riment6e en FRANCE. A I'aide de la presente invention, 
les applications qui viennent d'etre enumer6es sont virtuellement dans la 

30 carte. Le proprietaire de la carte les a chargees au prdalable ; ainsi, la cart 
est configuree selon ses propres besoins. 
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La prSsente invention permet aussi de resoudre un autre 
probleme. Un utilisateur peut avoir besoin d'ouvrir en m§me temps deux fois 
une mftme application. Uex6cution de cette application dans un dispositif de 
5 traitement de rinfonnatlon tel qu'une carte dure un certain temps. Pour 
accelSrer le traitement, II est avantageux de pouvoir commencer une 
seconde execution d'application avant la fin de la premiere. Ainsi, le m&me 
programme se dSroule deux fois en meme temps. 

10 Plus g^n^ralement, la presente invention peut Sgalement s'utiliser 

dans le domaine des dispositifs de traitement de Tinformation, autres que 
des cartes, dotes de ressources m6moire limitees. Ces dispositifs sont 
dot6s de moyens de communication avec le r^seau et, utilisent 
6ventuellement la carte ^ microprocesseur comme moyens de controle et de 

1 5 memorisation de codes de security. 

Le but est attaint par le fait que le dispositif de traitement de 
rinformation concern^ est dote d'un syst6me d'exploitation comprenant au 
moins trois fonctions : 
20 - Chargement d'informations applicatives. 

- Dechargement d'informations applicatives. 

- Execution d'informations applicatives. 

Pour acquerir une nouvelle application, le dispositif de traitement 
de rinformation re^oit des informations applicatives dans sa memoire 
25 programmable et contrfile ces informations. 

Lors d'une commande regue d'un lecteur cooperant avec le 
dispositif de traitement de rinformation en vue d'ex6cuter une application, le 
systeme d'exploitation du dispositif analyse le contenu de sa m6moire et 
determine s'il y a lieu d'appeler le reseau pour decharger un partie de sa 
30 m§moir , et/ou de recharger des informations applicativ s pr6c6demment 
ddchargees. 



A 

Lors du rechargement d'informations applicatives. le systdme 
d'exploitation du dispositif v^rifie que les informations chargdes ont 6t6 
validdes par elle dans le passS. Ces informations sont ensuite executees. 

5 Le r§seau peut etre consider^ comma una extension de la 

memoire programmable du dispositif de traitement de {'information celui-ci y 
envoie ce qu'il ne peut garder dans sa propre m6moire: 11 contrdle, lors du 
rechargement. que les informations repues du r6seau sont bien celles qu'il 
avait prSalablement envoy6es. La memoire ROM du dispositif de traitement 

10 de {'information doit disposer d'un mScanisme de gestion de la memoire 
programmable qui lui permet de charger et d'exScuter un nombre illimitd 
d'application. Ods lors, les tailles des m^moires ROM et programmables du 
dispositif de traitement de Tinformation ne sont plus une limitation au nombre 
d'appllcations ex^cutables, et il n'y a plus besoin d'effectuer un nouveau 

1 5 masquage lors du rajout d'applications. 

En r^sumd, {'invention conceme un dispositif de traitement de 
{'information comprenant des moyens de traitement de {'information et des 
moyens de memorisation de I'informatton principaux, caract6ris6 en ce que 
les moyens de traitement comprennent : 

20 

- des moyens pour detecter. au cours du fonctionnement du dispositif 
de traitement de {'information, que {es moyens de memorisation principaux 
contiennent un voiume d'informations te{ qu'un stoclcage supplementaire 
d'un ensemb{e donn^ d'informations a stoclcer n'est pas possib{e ; 
25 - des moyens pour s6lectionner, dans les moyens de memorisation 

principaux, un ensemble d'informations e d^charger, dont {e d^chargement 
peut liberer dans les moyens de memorisation principaux un espace 
sufTisant pour autoriser ie stod<age dudit ensemble d'informations a stoclcer 
• 

30 * des moyens pour decharger I'ensemble d'informations d decharger 

dans des moyens de memorisation secondaires, dans (e cas ou lesdits 
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moyens de memorisation secondatres ne contiennent pas ledit ensemble 
d' informations d ddcharger ; et 

- des moyens pour stocker dans les moyens de memorisation 
principaux I'ensemble d'informations d stocker. 

5 

L'invention conceme aussi le procddd associd. 

D'autres details et avantages de la pr^sente invention apparaltront 
au cours de la description suivante de quelques modes d'exdcution pr6f6r6s 
10 mais non limitatifs. en regard des dessins annexes sur lesquels : 

La figure 1 repr^sente un rSseau de traitement de donn^es utilise 
par l'invention ; 

La figure 2 repr^sente un dispositif de traitement de 1' information, 
utilise dans la figure 1 et coop6rant avec une carte S puce ; 
15 La figure 3 reprSsente une variante de la figure 2, dans laquelle le 

dispositif de traitement de Tinformatton intdgre les fonctionnalites de la carte 
a puce ; 

La figure 4 est une variante de la figure 2. oCi le disp)ositif de 
traitement de I'information est ^quipd d'un dispositif de lecture d'une piste 
20 optique ; et . 

La figure 5 reprSsente une variante de la figure 3. 

Sur la figure 1 . un terminal 20. apte d lire une carte ^ puce , ou un 
terminal 22 integrant des fonctionnalites de carte a puce cooperent avec des 

25 banques de donnSes 23 d 25 distantes et reliees ^ ceux-ci par un rdseau de 
communication de donn^es 26. Le r^seau de communication de donn^es 26 
est notamment un r^seau teiSphonique, le r^seau Internet, ou tout autre 
reseau de communication de donn^es. Chaque banque de donnSes 
comprend une unit6 centrale de traitement de donn6es g6rant une m6moir . 

30 Selon Tinvention, et comme pr6cis6 ci-aprfes. la carte 21 ou le terminal 22 
peuvent, lorsqu'ils d6t ctent qu I chargem nt d'une nouvelle application 
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dans ceux-ci n'est pas possible en raison d'un manque de place memoir . 
decider de dScharger vers une des banques de donndes 23 d 25 une autre 
application. Ce ddchargement libdre un espace memoire sufTisant pour 
accueillir la nouvelle application. Si la carte 21 ou le terminal 22 ont 
5 ultdrieurement besoin de Tapplication dediargee, ils enverront une 
commande k la banque de donndes correspondante pour recharger 
rappltcatibn , aprds avoir, le cas 6chdant Iib6r§ § nouveau de la place 
mdmoire par un d^chargement d'application. 

La constitution du terminal 20 et de la carte 21 est prdcisde sur la 
figure 2. Le terminal comprend de fagon connue en soi un microprocesseur 2 
auquel sont reli6s une memoire ROM 3, et une memoire RAM 4, des moyens 
5 pour coopdrer, avec ou sans contact physique, avec la carte k puce 21 , et 
une interface de transmission 7 permettant au terminal de communiquer avec 
le r^seau de communication de donnees 26 de la figure 1 . Le terminal 20 
peut en outre &tre 6quip6 de moyens de stockage tels que des disquettes ou 
disques amovibles ou non, de moyens de saisie (tels qu'un clavier et/ou un 
dispositif de pointage du type souris) et de moyens d*affichage. ces diffdrents 
moyens n'etant pas repr6sent§s sur la figure 2. 

Le terminal peut 6tre constitud par tout appareil informatique install^ 
sur un site prtv6 ou public et apte d fournir des moyens de gestion de 
rinformation ou de d6livrance de divers biens ou services, cet appareil 6tant 
installe a demeure ou portable. 11 peut notamment s'agir aussi d*un appareil 
d6di§ aux telecommunications. 

Par ailleurs. la carte 21 porte une puce incluant des moyens de 
traitement de rinformation 9. une memoire non volatile 10. une m6moire 
volatile de travail RAM 14. et des moyens 13 pour coopdrer avec le terminal 
30 20. Cette puce est agenc^e pour definir, dans la memoire 10, une zone 
secrdte 11 dans laquelle d s informations une fois enregistrd s, sont 
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inaccessibles depuis t'ext^rieur de la puce mais seulement accessibles aux 
moyens de traitement 9, et une zone acx:essible 12 qui est rendue accessible 
depuis rextSrieur de la puce par le microprocesseur 9 pour une lecture et/ou 
une ^iture d'informations. Chaque zone de la memoire non volatile 1 0 p>eut 
5 comprendre une partie non modifiable ROM et une partie modifiable EPROM, 
EEPROM. ou constitu§e de m6moire RAM du type 'flash" ou FRAM (cette 
demidre etant une mdmoire RAM ferromagnetique), c*est-^-dire prSsentant 
les caractdristiques d'une memoire EEPROM avec en outre des temps 
d'acces identiques d ceux d'une RAM claissique. 

10 

En tant que puce, on pourra notamment utiliser un 
microprocesseur autoprogrammable S memoire non volatile, tel que dScrit 
dans le brevet amdricain n*" 4.382.279 au nom de la Demanderesse. Comme 
indiqud en colonne 1, lignes 13-25 de ce brevet, le caractdre 

15 autoprogrammable de la puce correspond a la possibility pour un 
programme fi situe dans une m6moire ROM, de modifier un autre 
programme fj situd dans une memoire programmable en un programme gj. 
Dans une variante, le microprocesseur de la puce est remplac^ - ou tout du 
moins complete - par des circuits logiques imptantds dans une puce a semi- 

20 conducteurs. En effet, de tels circuits sont aptes a effectuer des calculs, 
notamment d'authentification et de signature, gr§ce a de r^lectronique 
cablee, et non microprogramm§e. Hs peuvent notamment §tre de type ASIC 
(de Tanglais « Application Specific Integrated Circuit »). A titre d'exemple 
d'ASIC, on peut citer le composant de la society SIEMENS commercialism 

25 sous la r^f^rence SLE 4436 et celui de la societe SGS-THOMSON 
commercialis§ sous la reference ST 1335. Avantageusement, la puce sera 
con^ue sous forme monolithique. 

Une variante de la figure 2 est illustrSe sur la figure 3. ou I 
30 terminal 22 de la figure 1 comprend, outre les 6l6ments du t rminal 20, ceux 
de la carte 21 dispos6s dans un module 15. les 'lements communs aux 
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deux figur s 2.3 portant les mfemes r6f6rences. Toutefois» les moy ns de 
coop6ration 5,13 de la figure 2 sont remplac6s par une liaison permanente 
antra le microprocesseur 2 et le microprocesseur 9. 

5 Une variante de la figure 3 est representee sur la figure 5. Id. le 

terminal 50 ne comprend qu'un seul microprocesseur 51 ou equivalent , relie 
d une m6moire RAM 52 et d urie m6moire ndn volatile 53. La memoire non 
volatile 53 comprend una zone 54 rendue accessible de Texterieur du 
terminal par le microprocesseur 51, et une zone secrete 55 accessible 

10 seulement au microprocesseur 51. Le microprocesseur 51 possede la 
caracteristique autoprogrammable du miaoprocesseur 9, decrite en relation 
avec la figure 2. Enfin, le terminal 50 possede une interface de transmission 
56 lui permettant de communiquer avec le reseau de communication de 
donnees 26 de la figure 1 . 

15 

La description qui suit fera reference, de fafon non limitative, k la 
forme de realisation de la figure 2 et le terminal 20 sera denomme 
€ lecteur » en raison de sa fonction lecteur de la carte 21. mais il est clair 
que cette description se transpose a la forme de realisation de la figure 3 ou 
20 de la figure 5. Sur la figure 3. le module 15 aura les memes fonctionnalites 
que celles de la carte 21 de la figure 2. 

Les memoires de la carte sont organisees de la fa^on suivante : 
une memoire de type ROM, une memoire de travail de type RAM. et une 

25 memoire programmable non volatile do type EEPROM ou FLASH. Comme 
represente sur le tableau 1, la m6moire ROM contient une zone de systeme 
d'exploitation de base comprenant au minimum des sous-programmes ou 
routines telles que celles d'entree/sortie et d'ecriture/lecture en m6moire et 
une zone de systeme d'exploitation d'une memoire virtuelle, cette memoire 

30 virtuelle etant constituee par la memoire des banques de donnees 23 d 25. 
Le systeme d'exploitation d base et le syst6me d'exploitation de la memoire 
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virtuelle forment ensemble ce que Ton appellera par la suite le « syst^me 
d'exploitation de la carte ». 

Le systdme d'exploitation de la memoire virtuelle est capable de 
5 g6rer de preference au moins neuf commandes. Quatre commandes au 
moins sent lancdes par le lecteur vers la carte : 

- Chargement d'applications en carte; 

- Execution en carte des applications prdc6demnnent charg^es. 

- Effacement d'applications en carte. 

1 0 - Contrdle de presence d'applications en carte. 

Cinq autres comrr^andes sont lancSes par la carte vers le lecteur : 

- Dechargement d'applications vers le r6seau . 

- Rechargement d'applications depuis le reseau. 

- Suspension du processus de chargement . 
15 - Reprise du processus de chargement. 

- EfTacement d'applications dans le rSseau. 

Dans une realisation particulidre, le systdme d'exploitation de la mdmoire 
virtuelle flltre et transmet au programme de Tapplication charg6 en m6moire 
programmable, tous les ordres re^us de TextSrieur qui doivent 6tre trait^s 
20, par ce programme. 

Dans le present texte, le terme « information » designe tout 
programme executable ou donn^e non executable en general. Le terme 
« application » designe un programme particulier, destine k mettre en 
25 oeuvre une application d'un foumisseur de services ou de produits, et des 
donnees d'application associees.. 

Toujours selon le tableau 1 , la memoire programmable comporte 
au minimum trois zones : 

-une premiere zone dit " des donnees de systeme " contenant un code "C" 
30 identifiant la carte ; 
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-une seconds zone dite « de donndes de gestion » contenant des donn6es 
de gestion des applications . d savoir une cl6 de signature dite " SWAP " 
particuti^re h chaque carte, une ou plusieurs cl6s de chiffrement liSes selon 
le cas h des foumisseurs d'applications ou ^ des applications particulidres, 
5 et un tableau appel6 TAB.APPLI et 

-une troisidme zone dite « de chargement utilis^e pour recevoir las 
informations d'applications, c'est-S-dire du programme executable et/ou des 
donn^es ndcessaires au fonctionnement de ce programme. 

10 Au depart, la carte peut dtre donn^e k son porteur avec une zone 

de chargement et un tableau TAB_APPLI vides. Au moins la cl6 SWAP est 
situ^e dans la zone secrete 11 de la memoire non volatile 10 de la carte. 



Zone de chargement des informations d'applications 



Zone des donn6es de gestion (SWAP. TAB_APPLI. .) 
Zone des donnees de systdme (code C ) 



Zone du systeme d'exploitation de la m6moire virtuelle 

(ROM) 



Zone du systeme d'exploitation de base 
(ROM) 

Tableau 1 

15 

Le tableau TAB.APPLI contient les informations correspondent 
aux applications disponibles dans la carte, soit que ces applications sont 
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physiquement cont nues en carte . soit qu'elles sont virtuellement 
contenues en carte car decharg^es vers le reseau. II a la structure suivante : 



Code de 


Adresse de 


nombre 


Signature 


Chargement/ 


rapplication 


stockage 


d'octets 


des informations 


D^chargement 


1 


ADR-I 


1 


SGN-I 


Charge 


J 


ADR-J 


m 


SGN-J 


Ddchargd 


K 


ADR-K 


n 


SGN-K 


Charg6 



Tableau 2 : TAB APPLI 
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Le tableau TAB.APPLI 2 comprend autant de lignes que d'applications 
rendues disponibles par la carte et, pour chaque ligne, cinq colonnes. Une 
premidre colonne d^finit un code d'identification l,J,K de I'application. Une 
deuxieme colonne d^finit une adresse de stockage ADR-I.ADR-J.ADR-K d 

10 partir de laquelle rapplication est stockee en carte. Une troisieme colonne 
d6finit un nombre d'octets representant la quantite d'informations de 
rapplication. Une quatridme colonne d^finit une signature portent sur 
I'ensemble des octets de rapplication . calculee en utilisant un algorithme et 
la cl6 SWAP de la carte en tant que cle secrete. En tant qu'algorithme , on 

15 peut utiliser un algorithme symetrique tel que le D.E.S. (de I'anglais Data 
Encryption Standard) ou asymetrique tel que le R.S.A. (des auteurs Rivest, 
Shamir et Adieman) ; avantageusement cependant, il suffira d'utiliser une 
fonction plus simple, telle qu'une fonction de hachage comme MD5 ou SHA, 
ou une fonction telle que le « ou exclusif », puisque, dans le cadre de 

20 I'invention , la signature ne sort pas de la carte et se trouve done pr^serv^e. 
Enfin, une cinquieme colonne definit si {'application concernee est dans un 
6tat « charge » en carte ou « d§charg6 3» dans une banque de donn^es. 

Dans un premier temps, un porteur de carte ou un foumisseur 
d'applications desire charger en carte une premier application ayant un 

25 code d'identification " K*. L'execution d*une commande de chargement peut 
dtre conditionnSe par une authentification de porteur ou de foumisseur 
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d'applications men6e a bien. Le mecanisme d'authentification bien connu en 
sot consists, pour le porteur ou le fournisseur d'applications, d foumir k la 
carte une information lui penmettant de s'assurer qu'elle dialogue avec un 
interlocuteur habilitS. 

La commands ds chargement contient un ordre de chargement, le 
code C de la carte, le code K de {'application et le nombre d'octets n 
d'ihformations correspondant d cette application, ce qui donne le format de 
commande suivant : 



Ordre de Chargement 



Carte C 



Appli K 



nombre n 
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Une fois la commande regue par la carte, le systeme 
d-exploitation de la carte v^rifie que le code C envoy§ est-bien !e m6me que 
celui enregistr^ dans la zone des donn^es de systeme . Dans la negative, la 
carte renvoie au rdseau un message d'erreur. Dans rafTirmative, les 

15 informations de Tapplication sont done bien destinees k cette carte : le 
systeme d'exploitation de la carte lit alors le tableau TAB_APPLI dans la 
zone des donn^es de gestion pour determiner s'il s'agit d'un chargement 
initial ou non, Au depart, TAB^APPLI ne contient pas d'informations sur 
I'application K ; si ce n'est pas le cas, la carte r^pond au lecteur par le 

20 message « application d§jS chargee » ; si c'est le cas. il s'agit done d'un 
chargement initial. Le systdme d'exploitation de la carte determine si les n 
octets peuvent 6tre logds dans sa mSmotre : dans Taffirmative, elle calcule 
I'adresse de d^but ADR-K " d'un premier bloc de n octets disponibles dans 
la zone de chargement. Dans la negative, elle renvoie le message 

25 « m6moire insuffisante », Enfin, la carte indique au lecteur qu'il peut envoyer 
les n octets de Tapplication, d I'aide de la r6ponse " OK_Chargement Le 
lecteur envoie alors les n octets de Tapplication . 



Une fois les informations de Tapplication stockSes n memoir 
30 programmable, le systeme d'exploitation de la carte calcule la signature 
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« SGN-K » de ces informations, il rentre alors dans le tableau TAB.APPLI 
le code d'application K, Tadresse de stockage ADR-K, le nombre d'octets n, 
et la signature SGN-K. Une fois cette operation effectuee, I'indicateur 
" Chargement/D6chargement " est positionne sur " Chargd La mise h jour 
5 du tableau TAB_APPLI etant terminee. le systeme d'exploitation de la carte 
peut alors envoyer un compte-rendu, d travers le lecteur, au porteur de carte 
ou au foumisseur d'applications, indiquant que le chargement de 
rapplication a 6t6 correctement effectu6. Le tableau TAB_APPLI poss&de 
alors la structure suivante : 

10 



Code 
de 

rapplication 


Adresse 

de 
stockage 


Nombre 
d'octets 


Signature 
des 
informations 


Chargement/ 
DSchargement 


K 


ADR-K 


n 


SGN-K 


Charge 


Ta 


bleau 3 : TAE 


\ APPLI 



Selon une premidre variante, le systeme d'exploitation de la carte 
peut lancer, juste aprds le chargement, le programme executable contenu 

15 dans les informations applicatives, c'est-a-dire dans les informations de 
rapplication. Ceci permet d'initialiser les informations applicatives. Par 
example, dans le cas d'une application Porte-Monnaie Electronique, la 
premiere execution du programme permet d'initialiser a 0 Frs le solde du 
porte-monnaie ecrit dans la m6moire. Selon une seconde variante, le 

20 programme executable est Ianc6 lors d'une premifere commande envoyee 
par le lecteur k la carte et faisant appel d rapplication consider^e. De fa^on 
simple. I'adresse de dSbut d'ex^cution de rapplication est « ADR-K 9, mais 
on peut utiltser un adressage indirect : I'adresse designee est alors, de 
fa9on connue en soi dans le domaine des microprocesseurs, le contenu de 

25 la memoir not6 [ADR-K] qui contient I'adress d'execution. 
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Le lecteur envoie d la carte des commandes en sp6cifiant le typ 
d'application ; par exemple. ce type peut 6tre cod6 dans le premier des cinq 
octets d'une commande selon la norma ISO 7816-3 ; cet octet est appel6 
dans la dite norme : « CLA ». Le systdme d'exploitation de la mdmoire 
5 virtuelle de la carte contrdle les commandes que lui envoie le lecteur et 
determine le code de rapplication correspondant d la commande. Puis, il lit 
dans le tableau TAB.APPLi si le code est 6crit ; si c'est le cas, la carte peut 
executer t'application K. Si ce n'est pas le cas, la carte ne peut ex6cuter 
rapplication K : elle rdpond en envoyant un message d'erreur. Si le code K 

10 est 6crit dans TAB_APPLI, la valeur de Tindicateur 
« Chargement/D§chargement » est ensuite testae. S'il est pcsitionnd sur 
« Chargement », les informations applicatives sont bien pr^sentes en 
memoire programmable de la carte. Dans ce cas, le systeme d'exploitation 
de la carte donne la rriain d un programme de rapplication situd d I'adresse 

1 5 ADR-K ou [ADR-K]. Nous aliens voir par la suite ce qui se passe lorsque la 
memoire programmable de la carte ne contient pas les informations 
applicatives. parce qu'elles ont d§ja ete decharg^es. 

Supposons maintenant que le porteur de carte ou le foumtsseur 
20 d'applications desire que sa carte contienne les informations d'une seconde 
application, notSe « J » par exemple. Cela est possible en chargeant les 
informations applicatives <( J )> dans la memoire programmable de la carte. 
De meme que precddemment, le porteur de carte ou le foumisseur 
d'applications s'authentifie en presentant un secret suivi de la commande de 
25 chargement d'informations applicatives suivante : 



Ordre de chargement 


Carte C 


Appli J 


nombre m 



Elle se presente comme la pr6c6dente relative au chargem nt de 
rapplication K ; ici, le nombre d'octets de rapplication est m. 

30 
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Le systeme d'exploitation de la carte verifie le code C et 
recherche le premier bloc de m octets disponible dans la m^moire 
programmable. Supposons que la memoire programmable ne peut 
physiquement contenir en mdme temps les deux blocs d'informations 
5 applicatives constitu§s par {'application K et rapplication J, mais qu'elle peut 
contenir I'appllcatton J si elie d6charge tout ou partie de rapplication K La 
carte informe le lecteur qu'elle suspend le processus de chargement de 
rapplication J d Taide d'une commande specifique envoyee au lecteur, et 
d^ide alors de dScharger rapplication K dans une banque de donndes qui 
10 peut etre consider6e comme la memoire virtuelle de la carte. Ce 
d6chargement va liberer de la place m6moire pour charger rapplication J. 

Le dSchargement consiste alors a transferer dans I'une des 
banques de donndes 23 k 25 du rdseau destin^e notamment d la carte 

15 actuelle, les informations applicatives particulieres h cette carte. Par le 
caicul de signature effectud lors du chargement. la carte est assur6e de 
pouvoir contrdler rint6grite et rauthenticit6 de ses propres informations lors 
d'un rechargement ulterieur. De plus, le fait d'avoir dejS effectu6 le caicul de 
signature lors du chargement initial optimise le temps d'ex6cution de la 

20 commande de dechargement. La carte envoie au lecteur la commande 
suivante : 



Ordre de dechargement 


Carte C 


Appli K 


nombre n 


n octets 


vers le rdseau 








d'informations 



Cette commande comporte. comme la commande de chargement, 
25 le code C de la carte, celui K de rapplication d d6charger ,et le nombre 
d'octets n d'informations de rapplication ; elle comporte en plus le contenu 
mfeme de ces n oct ts d'informations. transmis au lecteur en mem temps 
que rordre de dechargement. Dans le cas ou le dechargement de 
rapplication intervient alors qu'une partie de celle-ci a d6j^i 6t6 ex6cut6e, 
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des informations de contexte, permettant de reprendre ultSrieurement 
r execution de I'application k i'endroit oCi elle a 6td interrompue, sont, soit 
stock^es dans la m§mojre programmable de la carte , soit ajoutSes aux n 
octets d'informations de I'application et dechargSes en m&me temps qu'eux 
5 dans le reseau. 

II est possible d'ihdiquer uh idehtifiant de destinataire sous la 
forme d'une adresse de rdseau. Avantageusement, le reseau poss^de une 
table de correspondence qui associe cheque carte d Tadresse de la banque 
10 de donn6e qui lui est notamment destinSe. Ceci permet d'6viter k la carte 
d'avoir k stocker ladite adresse ou ledit identifiant, et de rassembler dans 
une mSme banque de donnSes toutes les informations d6charg6es k partir 
d'une mfeme carte. 

15 Le lecteur re9oit la commande. mais reconnalt qu'elle est destinde 

au r6seau : il la renvoie done vers la banque de donn^es ^ laquelle elle est 
adressee. Si le reseau possdde plusieurs banques de donnees, le choix 
peut s'effectuer en fonction du code C de la carte. La banque de donn^e 
revolt les n octets d'informations applicatives et renvoie a la carte, via le 

20 lecteur. un accus6 de bonne reception indiquant que le stockage s'est bien 
passd. La carte modifie alors le tableau TAB.APPLI en posttionnant 
rindicateur Chargement/D6chargement sur ** D6charge La place m6moire 
occupee jusque-IS par les informations applicatives de Tapplication K 
deviant disponible. L'operation de chargement de Tapplication J peut alors 

25 reprendre et la carte envoie au lecteur une commande de reprise du 
processus de chargement ; reparation de chargement s*effectue de fagon 
identique d celle de K. Le syst&me d'exploitation de la carte determine 
Tadresse de stockage ADR-J des m octets de I'application J et indique au 
lecteur par un message « OK_Chargement » qu'il peut envoyer les m octets 

30 d'informations applicatives. 
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Le iecteur envoie les m octets d'infomnations applicatives qui sont 
Merits k partir de I'adresse *ADR-J*. Une fois les informations de 
rapplication J stockSes en memoire programmable, ie systdme d'exploitation 
de la carte calcule une signature de celles-ci en effectuant un calcul 

5 cryptographique a Taide de la cl6 SWAP. Enfin. le systeme d'exploitation 
met a jour le tableau TAB_APPLI en ecrivant le code J, les valeurs ADR-J, m 
et SGN-J. et met k jour Vindicateur " Chargement/D6chargement " en le 
positionnant sur " Chargd Le systdme d'exploitation peut ators envoyer au 
Iecteur un compte-rendu indiquant que le chargement a §t6 correctement 

10 effectu6. 



Le tableau TAB_APPLI possdde alors les valeurs suivantes : 



Code de 


Adresse 


nombre 


Signature 


Chargement/ 


rapplication 


stockage 


d'octets 


des donnSes 


D^chargement 


K 


ADR-K 


n 


SGN-K 


D^chargd 


J 


ADR.J 


m 


SGN-J 


Charge 



tableau 4 : TAB APPLI 
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Une fois termin6e la mise k jour du tableau TAB_APPLI, le 
systeme d'exploitation de la carte peut alors lancer rapplication J de la 
m&me fa^on qu'il a Ianc6 rapplication K et la carte execute la commando 
d*ex6cution que le Iecteur lui avait envoy6e. 

20 Si le porteur de carte ou le fournisseur d'applications connecte sa 

carte a un Iecteur et desire ex6cuter une nouvelle fois rapplication K, le 
systeme d'exploitation de la carte analyse le contenu du tableau TAB.APPLI 
pour determiner si cette application est accessible avec cette carte. Dans le 
cas present, rapplication K est bien enregistree dans TAB_APPLI, mais elle 

25 a etd ddchargee dans le reseau. Un autre application est en memoir , c'est 
J et elle occupe m octets. Le systeme d'exploitation teste alors si 
rapplication K qui occupe n octets en memoire peut &tre charg6e dans ce 
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qui reste disponible en mdmoire. Comme on Ta suppose pr^cddemment, la 
r^ponse d ce test est negative. Le systdme d'exploitation decide alors de 
d^charger Tapplication J actuelte pour pouvoir recharger rapptication K. 

5 La commande, dmise par la carte, de d^chargement vers le 

r6seau de J est : 



Ordre de ddchargement 


Carte C 


Appli J 


nombre 


m octets 


vers le r^seau 






m 


d'informattons 



L'op^ration une fois effectu^e, Tindicateur de chargement de 
10 rapplication J dans TAB_APPLI est mis en position « D^charge ». La place 
memoire ^tant maintenant disponible, le syst^me d'exploitation envoie au 
leoteur une commande de rechargement de rapplication K depuis le rdseau. 
Cette commande a le format suivant : 



Ordre de rechargement 


Carte C 


Appli K 


nombre 


a partir du r^seau 






n 



15 



Le lecteur revolt la commande et la renvoie vers la banque de 
donnSe associ^e ^ la carte C. La banque de donnee qui poss^de les 
informations de la carte C re^oit la commande et recherche dans le fichier 
20 de cette carte, les n octets d' informations applicatives relatives a 
rapplication K. La banque de donnees elabore le message suivant, qui est 
la r^ponse d la dernidre commande de la carte. Cette r^ponse est transmise 
d la carte via le lecteur : 



Carte C 


Appli K 


nombre n 


n octets de donnees 



25 
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Le systeme d'exploitation de la carte peut verifier que les codes 
5 C, K et la valeur n re^us^ sont bien identiques a ceux de la commande de 
d6chargement 6mise prdcddemment. Si Tidentit^ est r^aiisde, la commande 
se poursuit par la reception des n octets de donnees qui sont Merits d partir 
de I'adresse ADR-K dans la zone de chargement, cette adresse Stant k cet 
effet lue par le systdme d'exploitation dans le tableau TAB_APPLi ou 

10 rdcupdrde k partir des informations de contexte rechargdes. Dans le mdme 
temps, le systdme d'exploitation calcule la signature des n octets Merits par 
un calcul cryptograph ique utilisant la valeur de la cl6 SWAP. La signature 
recalculee est alors compar6e k la valeur ecrite dans le tableau TAB_APPLI. 
Si les donnees re9ues du r^seau ne sont pas identiques k celles 

15 dechargees pr6c6demment, les deux valours de signature ne seront pas 
6gales. II existe alors un doute sur I'authenticite ou rint6grK6 des 
informations revues. Les informations chargfees ne peuvent done pas 6tre 
ex^cut^es. La carte renvoie au lecteur un message d'erreur indiquant une 
reception dMnformations erronees au cours de la demiere operation de 

20 chargement, et Timpossibilite d'ex6cuter Tappllcation K ; le systdme 
d'exploitation ne met pas Tindicateur de chargement en position « chargd » ; 
le cas ^ch^ant, il peut effacer le contenu de Tapplication K. 

Si en revanche les deux valours de signature sont Sgales, les 
25 informations reQues correspondent bien d celles de I'application K 
pr^c^demment chargee dans la carte. Une fois ces contr6les effectues, le 
systeme d'exploitation de la carte met k jour le tableau TAB_APPLI en 
mettant I'indicateur de chargement de Tapplication K sur la position 
« Charge ». 
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L tableau TAB APPLI a alors les valeurs suivantes : 



Code de 
I'application 


Adressd de 
stockage 


nombre 
d'octets 


Signature 
des donn6es 


Chargement/ 
D6chargement 


K 


ADR-K 


n 


SGN-K 


Charg6 


J 


ADR-J 


m 


SGN-J 


D§chargd 


Ta 


bleau 5 : TAB APPLI 



5 Une fois termin6e la mise d jour du tableau TAB_APPLI, le 

syst^me d'exploitation lance Tapplicdtion K comme pr6cedemment. et la 
carte peut ex§cuter la dernidre commande de type applicative envoy6e par 
le lecteur. 



10 On a ddcrit pr^cddemment que, lors de la reception par ta carte 

d'une commande de chargement d'une application non actuellement 
stock6e, le systdme d'exploitatlon de ia carte teste la place disponible en 
mdmoire. Si celle-ci est suffisante, le chargement peut s'op6rer sans 
decharger Tapplication actuellement en mdmoire. II extste alors deux 

15 applications dans la carte. Le tableau TAB_APPLI prend alors la 
configuration suivante : 



Code de 
rapplicatlon 


Adresse de 
stockage 


nombre 
d'octets 


Signature 
des donnees 


Chargement/ 
DSchargement 


K 


ADR-K 


n 


SGN-K 


Charge 


1 


ADR-I 


1 


SGN-I 


Charg6 


J 


ADR-J 


m 


SGN-J 


D6charg§ 


Ta 


bleau 6 : TAB APPLI 



Dans cet exemple, deux applications I et K co-habitent dans la 
20 carte : elles sont directement ex^cutables. Une troisieme application J est 
accessible ^ Taide de cette carte, mais il faut la recharg r ^ partir du rdseau. 
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Les memoir s non volatiles de la carte cx^ntiennent les informations 
suivantes : 



ADR-K 


ADR-I 




Programme de 


Programme de {'application 




rapplication K 


1 




Donates 


Donndes 




de rapplication K 


de rapplication 1 


^^^^^^^^ 


Donn6es de gestion (cl6 SWAP. TAB_APPLI,...) 


Donri^s de systeme 






(codec.) 




Systeme d'exploitation de la mSmoire virtuelle 




(ROM) 




Systdme d'exploitation de base 






(ROM) 





Tableau 7 

5 

Ce tableau correspond au tableau 1 pr6cit6. dans lequel la zone 



de chargement est d§taill6e comme suit : on volt que la zone de chargement 
des informations applicatives comprend trois sous-zones : une zone 
recevant les informations de rapplication K. une zone recevant les 
10 informations de rapplication I, et une zone residuelle libre qui est de taille 
inf^rieure d m. 

A la lumidre de cat exemple, on comprend mieux les 
caract6ristiques de I'invention. La carte est dotee d'un syst6me d'exploitation 
15 minimum permettant de g6rer la place m6moire, de charger ou d6charger 
des applications, de signer les informations applicatives a dScharger vers le 
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r6seau. de verifier ies informations applicatives d6charg6 s et regues du 
r^seau en comparant ies signatures, et de lancer des applications charg^es 
dans la m^moire. La signature permet de verifier que Ies informations 
applicatives stockSes dans la banque de donndes ont bien 6td 

5 pr^alablement charg6es dans cette carte. Le tecteur est dotd d'un 
programme qui reconnalt Ies commandes de d§chargement et rechargement 
de la carte et de rtioyens pour transmettre Ies dites commandes au rdseau. 
Enfin, ie rSseau est ^uip6 de banques de donndes, la m^moire de ces 
banques pouvant dtre consid^r^e comme une extension de la m^moire 

10 programmable de la carte. 

Comme on Ta vu en preambule. Tinscription de routines dans la 
m6moire programmable pour modifier le fonctionnement du programme en 
ROM ne peut &tre rSalis^e que par des personnes connaissant ce 

1 5 programme. Les sauts vers ces routines et leurs retours dans le programme 
en ROM n6cessitent de connaitre pr6cis6ment les adresses, les param6tres 
d'entr^e et de sortie de ces routines, ruttlisation de la m^moire de travail, 
..etc. La pr6sente invention r6sout ce probl6me en 6vitant d'utiliser ces 
routines et, par voie de consequence, de divulguer les specifications de ces 

20 routines, tout en autorisant rex6cution de nombreuses applications. Les 
programmes applicatifs s'ex6cutent en faisant le moins possible appel au 
programme en ROM. Le concepteur de ce programme peut indiquer les 
points tfentrde d certaines routines dites 6lementaires : reception d'octets, 
emission d'octels, ecriture de n octets en m^moire programmable, calcul 

25 cryptographique . . etc. 

Une premiere amelioration de Tinvention consiste e chiffrer les 
informations applicatives pour les proteger lors de leurs diff6rents transferts 
entre le dispositif de traitement de I'information destine d accueillir des 
30 applications (tel que la carte 21 ou le terminal 22 de la figur 1 ) et le reseau, 
et lors de leur stockage en dehors de la carte 21 ou du terminal 22. 
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Un premier chiffrement d'application conceme le chargement 
initial de rapplication par un foumisseur d'applications et utilise une cl6 de 
base secrete, detenue par le dispositif de traitement de rinformation et le 
5 foumisseur d'applications situe dans le rSseau ; dans le cas ou le dispositif 
de traitement de information est une carte, son iecteur ignore la cl6 de 
base. Avantageusement, cheque application est chtffrde avec une cl6 
diversifide propre, obtenue d partir de la cid de base et d'un diversifiant 
constitue par un param^tre sp^dfique de rapplication , par exemple son 
10 code K ou son adresse de stockage ADR-K dans la m^moire programmable. 
Ce diversifiant peut fetre stockd dans le tableau TAB^APPLI de sorte que le 
syst^me d'exploitation peut facilement le retrouver lors des commandes de 
chargement / d6chargement. 

15 Lors du chargement initial de rapplication par le foumisseur 

d'applications dans le dispositif de traitement de {'information 21 ou 22, ce 
foumisseur calcule la cle diversifi6e associee d cette application et chiffre 
rapplication au moyen de celle-ci avant de Tenvoyer dans le reseau ; a 
reception, le dispositif de traitement de information calcule la cl6 diversifi^e 

20 associ§e k cette application et la d^chiffre avec celle-ci, avant de la stocker 
dans la zone de chargement de la memoire programmable. 

Un second chiffrement de rapplication conceme les 
dSchargements et rechargements effectu§s par le dispositif de traitement de 

25 rinformation 21. 22. Lors d'un dechargement de rapplication par le dispositif 
de traitement de rinformation 21.22 vers une banque de donn6es, 
rapplication est k nouveau chiffr^e par ce dispositif. La cl6 de chiffrement 
utilis6e n'a pas d §tre partag^e par le dispositif de traitement de rinformation 
avec tout autre interlocuteur tel que le foumisseur d'applications : n'importe 

30 quell old g^nerSe par le dispositif de traitement de rinformation conviendra. 
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puisque c' st ce m&me dispositif, et lui seul, qui effectuera le d6chiffrement 
ult^rieur. 

Avantageusement. la carte peut utiliser le proc6d6 decrit par le 
5 document US-A-4,907,270 qui a pour objet de fournir un proc6d6 pour 
s'assurer de rauthenticit6 et de rint6grit6 d'un message chiffr6. 

Le chiffrement dScrit ci-dessus permet d'6viter que des 
informations applicalives puissent etre d§couvertes par un fraudeur, et 
empdche la copie frauduleuse des programmes applicatifs. 

10 

En plus des commandes d6crites pr6c6demment, il est possible 
de pr6voir deux commandes suppl6mentaires : une commande d'effacement 
d'applications. et une commande de contrdle de presence d'applications en 
carte. 

15 

La commande d'effacement d'applications consiste, pour le 
porteur de carte ou le foumisseur d'applications. k envoyer a la carte une 
commande destinee a supprimer les applications qui ne sont plus utilis6es ; 
son format est le suivant : 

20 



Ordre d'effacement 


Carte C 


Appli K 


nombre n 


d'applications 









Elle comprend un ordre d'effacement d'applications, le code C de la carte 
concem6e. le code K de I'application. et 6ventuellennent le nombre n 
d'octets d'informations de rappllcation. Si rappllcation concem6e est 
25 chargSe en carte , le systfeme d'exploitation de la carte rend disponible 
I'espace mdmoire r6sen/6 jusque-ld k rappllcation K. Si en revanche 
I'application K ^tait dScharg^e dans une banque de donn6es, la carte envoie 
vers celle-ci un ordre d'effacement qui a le mfeme format que celui ci-dessus. 
Enfin, un fois que lordre d'effacement a 6t6 ex6cut6, le systdm 
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dexploitation efface la ligne du tableau TAB^APPLI concemant cette 
application. 



La commande de contrdle de presence d'applications en carte 
peut prendre deux formes diff^rentes. La premiere forme de ia commande 
permet au porteur de carte ou au foumisseur d'applications de demander ^ 
la carte si elle possdde une application particuliere ; son format est le 
suivant : 



Ordre de contrdle de 


Carte C 


Appli K 


nombre n 


presence d'applications 









Elle comprend un ordre de contrdle de presence d'applications, le code C de 
la carte concem6e. le code K de I'application, et 6ventuellement le nombre n 
d'octets d'informations de ('application. 

La seconde forme de la commande permet au porteur de carte ou au 
foumisseur d'applications de demander d la carte Tensemble des lignes de 
son tableau TAB_APPLI , a ('exclusion bien 6videmment des signatures et 
6ventuellement du nombre n d'octets et de I'indicateur de chargement. Le 
format de la commande est le suivant : 



Ordre de contrdle de presence d'applications 



Carte C 



Une seconde amelioration de I'inventton consiste d ne d^clencher 
le d^chargement d'une application vers le r^seau que lorsque cela est 
n6cessaire. Si, au moment ou il faut Iib6rer de la m6moire, Tapplicalion 
charg^e n'a pas 6t6 modifi^e et si le r^seau poss&de d6jd les m§mes 
informations applicatives de cette application, il n'est pas utile de d6charger 
ces informations. La seconde am6lioration a pour objet d'§viter de stocker 
plusieurs fois les mdmes valeurs d'informations applicatives sur le r^seau. 
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Pour mettre en place cette am6lioration il faut modifier le tableau 
TAB APPLI, void la nouvelle structure : 



Code de 


Adresse de 


nombre 


Signature 


Chargement/ 


Modification 


rapplication 


stockage 


d'octets 


des 


06chargement 










informations 






K 


ADR-K 


n 


SGN-K 


Charg6/ 


OUI/ 










Dechargd 


NON 



5 Tableau 8 : TAB-APPLI 



On a ajoutd une sixi6me colonne au tableau, qui contient un 
indlcateur note ' Modification ", pouvant prendre deux valeurs : Oul ou Non. 
Lors du chargement initial d'une application, I'indicateur est positionn6 4 

10 " Oui " : cette valeur indique qu'il faut decharger les informations applicatives 
vers le r6seau pour Ilb6rer la place m6moire correspondante. Par centre, 
apres une commando de rechargement S partir du r6seau, I'indicateur est 
positionn6 S " Non " : cette valeur indique que les informations applicatives 
stock6es en m6moire programmable du dispositif de traitement de 

15 rinformation (carte 21 ou terminal 22 de la figure 1) sont identiques a celles 
memoris6es dans la banque de donnees du reseau. Tant que I'indicateur 
reste S « Non », le systeme d'exploitation du dispositif de traitement de 
rinformation n'effectue pas de commando de d6chargement de I'application ; 
il positionne uniquement I'indicateur de chargement en position 

20 « Decharg§ » pour qu'une autre application puisse occuper sa place en 
memoire. L'indicateur est positionne d " Oui " lorsque Ton modifie les 
informations applicatives ; par voie de consequence, la valeur de signature 
n'est alors plus exacte : 11 faudra la recalcuier lors du d6chargement. 

25 Cette modification peut intervenir dans au moins deux cas. Le 

premier cas est une mise d jour du programme applicatif. soit pour le rendr 
plus performant en rajoutant des fonctions suppl6mentaires, soit pour 
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coiTiger un ddfaut. Le second cas arrive frequemment lorsque, dans la 
mdmoire programmable du dispositif de traitement de Tinformation 21 ou 22 , 
des donn6es sont mdides au programme applicatif. Par example, une 
application porte-monnaie Slectronique contient d la fois le logidet pour 
5 gSrer les debits et las cr^its. mais aussi des donnees dont le solde. A 
chaque utilisation, cette valeur 6volue gdn§ralement et done, I'indicateur 
" Modification ' est presque toujours en position " Oui 

Ce dernier exemple am§ne k une troisi^me amelioration de la 
10 pr^sente invention. On voit que dans les informations appltcatives, existent k 
la fois du programme executable et des valeurs de donnees applicatives 
susceptibles d'Svoluer souvent. Les moyens d^crits dans la troisieme 
amelioration dScrite ci-apr^s permettent de bien sSparer les deux types 
d'informations. Le dispositif de traitement de ('information choisit alors de ne 
15 decharger vers le rdseau que les informations qu'il a effectivement 
modifiees. 

Pour realiser cette troisi6me amelioration, il convient de 
perfectionner I'organisation des mSmoires non volatiles, qui peut se 
20 schematiser de la fagon suivante : 
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Programme 
de I'application 
(m6moire programmable) 



Donn^es 
de rapplication 



Donn^es 
dvolutives 
sequence 1 



Donndes 
6volutives 
sequence 2 



Donn6es de gestion (cl6 SWAP, TAB_APPLI,...) en m6moire programmable 



Donnas de type syst6me en m6moire programmable 
(code C, ) 



Systeme d'exploitation de la memoire virtuelle 
(ROM) 



Systeme d'exploitation de base 
(ROM) 
tableau 9 



Le tableau 9 diffdre du tableau 1 pr6cit§ par la structure de sa 
5 zone de chargement de la m6moire programmable, qui se pr6sente comma 
suit : 

- un bloc relatif a I'application en tant que telle et comprenant deux sous- 
blocs d' informations : 
10 -un bloc relatif au programme executable de rapplication, not6 

« programme de I'application » ; 

- un bloc relatif aux donn6es (non ex6cutables) 6volutives de 
{'application, not6 « donn§ s de I'application » ; 

-un certain nombre de blocs de donn^es (non ex^cutables) 6volutives 
15 con-espondant d des ex6cutions particulidres du programm ex6cutable : 

ces executions sont appel^es par la suite des « sequences Par definition. 
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les donn§es d'une sequence sont temporaires, c'est-d-dire qu'elles ne sont 
utilis^es que tors de cette sequence , et pas lors des sequences 
precedentes ou suivantes. C'est ce qui les distingue des « donnees de 
I'application » pr^citSes. lesquelies sont utilis§es durant toutes les 
5 s^uences. Sur ie tableau 9, deux blocs de donnees de sequences sont 
repr^sent^s, notds « donn6es dvolutives sequence 1 » et « donn6es 
dvolutives s^uence 2 ». Le rdle de ces difT^rents blocs d'informations sera 
expltqu^ dans Texemple qui va suivre. 

10 Pour r6aliser cette troisieme amelioration, le tableau TAB_APPLI 

est modifid, il poss^de la structure suivante : 



Code 
application/ 
Num^ro de 
sequence 


Informations relatives 
au programme executable et 
aux donnees de rapplication 


informations relatives 
aux donnees evolutives 
des sequences notees € i > 


adresse 

de 
stockage 


nombre 
d'oct^s 


signatu- 
re 


Charge./ 
D^charge. 


adresse de 
stockage 


nombre 
d'octets 


signature 


Charge./ 
oecharge 


P/1 


ADR- 
Cod-P 


p-cod 


SGN- 
cod-P 


Charg6 


ADR- 
Dat.P/1 


p-dat 


SGN-dat-P/1 


Charge 


P/2 


ADR- 
Cod-P 


p-cod 


SGN- 
cod-P 


Charge 


ADR- 
Dat-P/2 


p-dat 


SGN-dat-P/2 


Charge 


J/1 


ADR- 
Cod-J 


j-cod 


SGN- 
cod-J 


Charge 


ADR- 
Dat-J/1 


j-dat 


SGN-dat-J/1 


Charge 


J/2 


ADR- 
Cod-J 


j-cod 


SGN- 
cod^ 


Charge 


ADR- 
Dat-J/2 


j-dat 


SGN-dat-J/2 


oecharge 



tableau 10 :TAB.APPLI 

15 

Vis-a-vis du tableau TAB_APPLI 2 pr6cit6, ce tableau pr6sente 
les differences suivantes. La premiere colonne sp^cifie, outre le code de 
rapplication . le numero « i » de la sequence concemee. Les informations 
traitees le sont en deux groupes : celles relatives au programme executable 
20 et aux donnees de I'application , et celles relatives aux donnees evolutives 
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des s6quences. Pour chaque groupe d' informations , on retrouve les quatre 
colonnes suivantes du tableau TAB_APPLI 2 : adresse de stockage , 
nombre d'octets , signature . indicateur de chargement, Chaque ligne du 
tableau correspond d une sequence donn6e P/1 ou P/2 toutes deux relatives 
5 d une application P, ou une s6quence J/1 ou J/2 toutes deux relatives ^ une 
autre application J. Dans diffdrentes cases du tableau , le code de 
rapplication est mentionn6 pour rappeler que la valeur consid6r6e est 
relative d une application donn§e ; par exemple : 

• ADR-Cod-P : adresse de stockage relative k rapplication P 
10 • j-cod : nombre d'octets relatif d rapplication J 

Par ailleurs, le symbole « Cod » indique que la valeur consid6r6e est 
relative d une information de type « application » (programme ou donn§es 
du premier groupe). tandis que « Dat » indique que la valeur consid§r§e est 
relative k une information de type « s6quence » (donn6es du second 
15 groupe) ; par exemple : 

• SGN-cod-P : signature d' informations (programme ou donn6es ) relatives 
k rapplication P 

• SGN-dat-J/2 : signature de donn§es relatives h la s6quence N*2 de 
20 rapplication J 

Un exemple d6cfira mieux le probl6me pos6 et la fagon de le 
rdsoudre en utilisant la presente invention. 

Le dispositif de traitement de I'information (carte 21 dans ce cas) 

25 vient de recevoir une commande de chargement initial de {'application P : 
application de paiement de type Porte-Monnaie Electronique (PME). Les 
informations applicatives stock6es en m6moire programmable sent le 
programme executable et les donn6es relatives d rapplication ; il n'y a pas 
encore de donn§es 6volutives correspondent k une sequence. Ces 

30 informations comprennent n-Cod octets stock6s d partir d'une adresse 
ADR-Cod-P. L'indicateur d chargement est positionn6 h « Charge En 
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plus des informations relatives au programme executable et aux donn6es de 
{'application, les informations transmises lors de la commande contiennent 
un nombre d'octets de donnSes ^volutives « p-dat » relatives ii une 
sequence i. Le tableau TAB_APPLI poss^e alors les valeurs suivantes : 



Code 

application 

Num^ro de 
s^uence 


a) 
a 


Informations relatives 
J programme executable et 
ux donn^es de rapplication 


informations relatives 
aux donn^es 6volutives 
des sequences notees « t » 


adresse 

de 
stockage 


nombre 
d'octets 


signature 


Chargd./ 
D^charg^. 


adresse de 
stockage 


nombre 
d'octets 


signature 


Charge./ 
Oecharge 


PAi 


ADR- 
Cod-P 


p-cod 


SGN- 
cod-P 


Charge 


0 


p-dat 


0 


0 



tableau 1 1 : TAB APPLI 



Les transactions sont vaiid^es par un circuit 6lectronique appeld 
module de s6curit6. Ce module peut se situer soit dans le terminal lecteur de 
carte 20 de la figure 1, soit, si on d6sire un maximum de s6curit6, dans un 
centre d'agrement bancaire qui peut se situer tres loin du terminal 20 . Une 
transaction de type P.M.E. se d6roule en plusieurs stapes qui necessitent 
des communications entre la carte, le terminal et le module de s6curit6. 
L'achat peut s'effectuer chez un commergant dot6 d'un terminal avec 
module, mais il F>eut aussi etre fait au domicile du porteur de la carte dont le 
terminal n'est pas dotd d'un module. 

La carte est sollicitee pour effectuer un achat par un ordre 
d'initialisation d'une transaction. Le systeme d'exploitation de la carte 
reconnait un ordre de type applicatif : il interroge alors son tableau 
TAB__APPLI. L'interrogation du tableau lui indique que {'application 
correspondant k I'ordre est bien charg6e et qu'aucune sequence n'a 6t6 
allou^e. Le system d'exploitation initialise alors une sequence en lui 
attribuant un num6ro , « 1 » par example. 11 alloue d cette s6quence une 
place m6moire de « n-dat » octets, d partir de I'adresse ADR-Dat-P/1. 
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L'indicateur de charg ment correspondant d cette sequence est positionnd 
sur « Chargd ». Le tableau TAB_APPLi possdde aiors les valeurs suivantes 



Code 
application 
/ 


Informations relatives 
au programme executable et 
aux donn^es de rapplication 


Informations relatives 
aux donn^es 6volutives 
des sequences not6es « i 


» 


Num6ro 


adresse de 


nombre 


signature 


Chargd./ 


adresse 


nombre 


signature 


Charge./ 


de 


stockage 


d'octets 




D6charg6 


de 


d'octets 




Dectiarge 


sequence 










stockage 








P/1 


ADR. 
Cod-P 


n-cod 


SGN- 
cod-P 


Charge 


ADR. 
Dat-P/1 


n-dat 


0 


Charge 



tableau TAB APPLI 12 



Puis, le syst&me d'exploitation de la carte lance le programme 
applicatif en effectuant un saut ^ Tadresse ADR-Cod-P ; il sp6cifie Tadresse 
ADR-Dat-P/1 des donn6es temporaires a utiliser, ce qui permet ^ 

10 rapplication de connaltre Tendroit ou sont memorisSes les donn^es de la 
s^uence. Ces donn^es sont, entre autres, le montant de la transaction, 
I'objet de la transaction, Torganisme vendeur et la date de la transaction. En 
revanche, une donn§e telle que le solde du porte-monnaie 6lectronique 
n'est pas une donn^e temporal re de sequence, car sa dur^ de vie ddpasse 

15 celle d'une sequence ; etant de type applicative, cette donnee est 
m6moris6e avec le programme de rapplication. 

L'achat d'un premier produit est en cours : la carte envoie alors au 
lecteur 20 un message en vue d'obtenir une validation de la transaction 
20 auprds d'un centre de paiement accessible par le rSseau. Cette 
communication peut durer un certain temps. En effet, les communications 
peuvent &tre perturbSes et les donnees envoy^es peuvent 6tre longuem nt 
analysSes par le centre d'agrdment bancaire. Tout cela provoque un 
altongement de la durd globale de la transaction. Pendant ce temps, 
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I'utilisateur d6dde d'effectuer un second achat. La presents inv ntion va 
permettre d'6viter d'attendre la fin de la premiere transaction pour 
commencer la seconde. 

5 Pour effectuer ce second achat, la carte est solliclt§e une 

seconde fois par un nouvel ordre d'initiallsatlon d'une transaction. De m&me 
que pr6c6demment, le syst^me d'exploitation de la carte v^rifie que le 
programme executable de I'applicatlon PME est chargSe en mdmoira 
programmable. Cette verification s'effectue en interrogeant son tableau 

10 TAB_APPLI ; le systdme d'exploitation reconnalt alors la presence du 
programme et d'une sequence (1) qui est en cours. Pour cela, il affecte d 
cette seconde execution un nouveau num6ro de sequence (2) et initialise le 
tableau TAB_APPLI en rajoutant une nouvelle ligne d celui-ci. Puis, ii verifie 
s'il existe suffisamment de place pour allouer dans la memoire 

15 programmable n-dat octets pour les informations de types donn^es non 
ex6cutables. Si la place est suffisante. une nouvelle adresse ADR-Dat-P/2 
est determinee et la seconde transaction peut §tre lanc^e. Le tableau 
TAB_APPLI poss^de les valeurs suivantes : 



20 



Code 
application / 


Informations relatives 
au programme executable et 
aux donn6es de Tapplication 


informations relatives 
aux donnees evoluttves 
des sequences notees < i » 


Num^ro de 
sequence 


adresse 

de 
stockage 


nombre 
d*octets 


signature 


Charge./ 
Oechargd 


adresse de 
stockage 


nombre 
d'octets 


signature 


Charge./ 
Decharg 

e 


P/1 


ADR- 
Cod^ 


n-cod 


cod-P 


Charge 


ADR- 
Dat-P/1 


n-dat 


0 


Charge 


P/2 


ADR- 
Cod-P 


r>-cod 


SGN- 
cod-P 


Charge 


ADR- 
Dat-P/2 


fMjat 


0 


Charge 


tableau 1 


rAB_APPLI 13 







Les deux transactions seront alors reaiis^es en paralldle dans la 
carte, sans faire appel au r§seau. Le lecteur doit indiquer dans les 
commandes applicatives envoyees d la carte, de quelle transaction il s'agit. 
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Si la place est insuffisante, le syst^me d'exploltation de la carte 
decide de d6charger unlquement ies donnSes dvolutives correspondant S la 
premiere transaction (num6ro de sequence 1). II calcule alors la signature 
5 des dites donndes de la premiere s6quence « SGN-dat-P/1 », et I'inscrit 
dans le tableau TAB_APPLI. Les nouvelles donn^es non exdcutables 
pdurront ainsi dtre d la m6me place que les donn^es dScharg^esr c'est-d- 
dire d une adresse commune aux deux sequences et not^ ADR-Dat-P. 
Puis, la carte envoie au lecteur la commande suivante : 

10 



Ordre de d^chargement vers 


Carle C 


Appli P - Data - 


nombre 


« n_dal » 


le r6seau 




num6ro de sequence 


n_dat 


octets de 






1 




donn^es 



Cette commande est de structure identique S celle precit^e, avec la 
difference suivante : la troisldme case contient im paramdtre sp^ifiant non 
seulement le code P de I'application , mais aussi le fait qu'il s'agit de 
15 donn6es de type sequence (par le terme « Data »), et le num6ro 1 de la 
sequence concem6e. 

A la suite de cette commande, le tableau TAB_APPLI poss6de les 
valeurs suivantes : 

20 



Code 
application / 
Numdro de 
sequence 


Informations relatives 
au programme executable et 
aux donn6es de rapplicatior. 


informations relatives 
aux donnees evolutives 
des sequences notees « i 


» 


adresse 

de 
stockage 


nombre 
d'octets 


signature 


Charge./ 
Oecharge 


adresse de 
stockage 


nombre 
d'octets 


signature 


Charge./ 
Decharge 


P/1 


ADR. 
Cod-P 


n-cod 


SGN- 
cod-P 


Charge 


ADR- 
Dat-P 


n-dat 


SGN-dat. 
P1 


Decharge 


P/2 


ADR- 
Cod-P 


n-cod 


SGN- 
cod-P 


Charge 


ADR- 
Dat-P 




0 


Charge 



tableau TAB APPL1 14 
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Suite d cette operation, la seconde transaction portent le num^ro 
de sequence 2 peut se poursuivre. Cette nouveile transaction n6cessite 
aussi una validation de la part du centre de paiement : une demande est 
5 done dmise vers le module de s§curit§. Supposons que la carte resolve d ce 
moment un message de validation de la premidre transaction. Le syst&me 
d'exploitation de la carte reconnait, k Taide du numdro de sequence, que ce 
message conceme une autre transaction que cetle en cours et, par la lecture 
du tableau TAB.APPLI, il reconnait la premiere transaction. Pour la trailer, il 
10 doit done charger ies donnees non ex^cutables de la premidre transaction. 

Sachant que la place memoire est insuffisante pour Ies deux blocs 
de donnees, le systdme d'exploitation de la carte doit done dScharger Ies 
donnees de la seconde transaction. II calcule alors la signature des dites 
15 donn6es « SGN-dat-P/2 et Tinscrit dans le tableau TAB_APPLL Puis, la 
carte envoie au tecteur la commande suivante : 



ordre de dechargement vers 


carte c 


appli p - data - 


nombre 


€ n.dat » 


le reseau 




numero de sequence 
2 


n_dat 


octets de donnees 



20 



Le tableau TAB_APPLt poss^de alors Ies valeurs suivantes 



Code 
application / 
Numero de 
sequence 


Informations relatives 
au programme executable et 
aux donnees de rapplication 


informations relatives 
aux donnees evolutives 
des sequences notees c 1 » 


adresse 

de 
stockage 


nombre 
d'octets 


signature 


Charge./ 
Oecharge 


adresse de 
stockage 


nombre 
d'octets 


signature 


Charge./ 
Decharg 

e 


P/1 


ADR- 
Cod-P 


n-cod 


SGN- 
cod-P 


Charge 


ADR. 
Dat-P 


n-dat 


SGhMjat- 
P/1 


Decharg 

e 


P/2 


ADR. 
Cod-P 


n^cod 


SGN- 
cod-P 


Charge 


ADR- 
Dat-P 


n-dat 


SGN^dat- 
P/2 


Decharg 

e 



tableau TAB APP 



L1 15 
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Le systdme d'exploitation de la carte envoie alors au lecteur la 
commande suivante : 



Commande de rechargement 


Carte C 


Appli P - Data - num6ro 


nombre 


d partir du r^seau 




de sequence 1 


n-dat 



5 



Cette commande diffdre de la commande de rechargement d6jd ddcrite en 
ce que la troisieme case contient un paramdtre specifiant non seulement le 
code P de rapplication , mais aussi le fait qu'il s'agit de donn6es de type 
sequence (par le terme « Data »), et le num6ro 1 de la s6quence concem6e. 

10 

Le lecteur re^it la commande et la renvoi© vers la banque de 
donn6e affectde notamment d la carte C. La banque de donnee recherche 
dans le fichier de cette carte, les n-dat octets de donn6es non ex6cutables 
relatives ^ I'appllcation P, num6ro de s6quence 1. La banque de donn6es 
15 elabore le message suivant, qui est la r6ponse d la demidre commande de 
la carte ; cette r6ponse est transmise d la carte via le lecteur : 



Carte C 


Appli P - Data- num6ro 


n-dat 


n-dat octets de 




de sequence 1 




donndes 



Cette commande diff6re de la r6ponse S une commande de rechargement 
20 d6jS decrite en ce que la deuxi6me case contient un paramfetre specifiant 
non seulement le code P de rapplication , mais aussi le fait qu'il s'agit de 
donn6es de type sequence (par le terme « Data »), et le num6ro 1 de la 
sequence concern6e. 



25 



L systeme d'exploitation de la carte peut effectuer une operation 
pr6liminaire selon laquelle il v6rifie que les codes C. P, le num§ro d© 
sequence et la valeur n-dat refus, sont bien identiques d ceux de la 
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commande emis pr6cedennment. Si I'identite est realisee, les n-dat octets 
re9us sont m§moris6s d partir de I'adresse AOR-dat-P lue dans le tableau 
TAB^APPLI . Une fois le dernier octet 6crit, le systeme Sexploitation 
recalcule la signature des donn6es it I'aide d*un calcul cryptographique 
utilisant la valeur de la cle SWAP. La signature recalcul6e est alors 
compar6e a la valeur « SGN-dat-P/1 » ecrite dans le tableau TAB_APPLI. SI 
tes deux valeurs de signature ne seront pas 6gales7 les donn6es refues du 
rdseau sont consid6r6es commee non identiques ^ eel les dSchargdes 
pr6c6demment. 11 existe done un doute sur i'authenticite_ou rintSgritS des 
donn^es regues. La carte renvoie au lecteur un message d'erreur indiquant 
la reception de donn^es errondes au cours de la demiere operation de 
chargement, et rimpossibilit^ de continuer la transaction. 

Si les deux valours sont 6gales, les donndes revues sont 
consid6r6es comme identiques d cellos pr^c^demment d6charg6es par la 
carte la premiere transaction peut done continuer. Le systeme 
d'exploitation de la carte met ensuite d jour le tableau TAB^APPLI en 
positionnant Tindicateur des donnees de Tapplication P/1 d « Charg6 » : 



Code 
application / 
Num^ro de 
sequence 


Informations relatives 
au programme executable et 
aux donnees de I'application 


informations relatives 
aux donndes 6volutives 
des sequences not6es « i » 


adresse 

de 
stockage 


nombre 
d'octets 


signature 


Chargd./ 
D6charg6 


adresse de 
stockage 


nombre 
d*octets 


signature 


Charge./ 
Oecharge 


P/1 


ADR- 
Cod-P 


n-cod 


SGN- 
cod-P 


Charg'i 


ADR- 
Dat-P 


n-dat 


SGN^at- 
P/1 


Charge 


P/2 


ADR- 
Cod-P 


n-cod 


SGN- 
cod-P 


Charg6 


AOR- 
Dat-P 


n-dat 


SGr4-dat- 
P/2 


Oecharge 



tableau TAB APPL1 16 



La mise ^ jour du tableau TAB_APPLI ^tant termln6e, le systdme 
d'exploitation lance rapplication P qui va continuer la premiere transaction. 
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La premiere transaction dtant termin^e, Texdcution du programme 
de rapplication se termine par un retour au systdme d'exploitation gdrant la 
m6more virtuelle. Le syst^me d'exploitation reconnalt alors la fin de la 
5 s^uence « 1 » et decide de lib^rer la place m6moire correspondant aux 
donndes de la dite sequence. Pour cela, il efface les informations « adresse 
de stockage ». « signature » et rindicateur de chargement/d6chargement en 
les mettant d la valeur z6ro. 



10 



Le tableau TAB APPLI a alors les valeurs suivantes 



Code 
application / 
Num^ro de 
s6quence 


Informations relatives 
au programme executable et 
aux donn6es de rapplication 


informations relatives 
aux donnees evolutives 
des sequences notees « i » 


.adresse 

de 
stockage 


nombre 
d'octets 


signature 


Charge./ 
D6charg6 


adresse de 
stockage 


nombre 
d'octets 


signature 


Charge./ 
Decharge 


P/1 


ADR- 
Cod^ 


n-cod 


SGN- 
cod-P 


Charge 


0 


n-dat 


0 


0 


P/2 


AOR- 
Cod-P 


n-cod 


SGN- 
cod-P 


Charge 


ADR- 
Dat-P 


n^lat 


SGN-dat- 
P/2 


□echarge 



tableau TAB.APPL1 17 
Lorsque la carte re9oit la validation de la seconde transaction, le 
syst^me d'exploitation de la carte reconnalt, a Taide du numero de 
sequence, que ce message concerne une autre transaction qui n'est pas 
15 chargSe. La premiere transaction 6tant terminSe, les donnees non 
exScutables correspondantes ne sont plus utiles. II n'y a done pas lieu de les 
decharger. II suffit done de charger les donnees non ex^cutables 
correspondant d la seconde transaction. Le systeme d'exploitation envoie au 
lecteur la commande suivante : 

20 



Commande de rechargement 


Cart 


Appli P - Data - numSro 


nombr 


k partir du rdseau 


0 


de sequence 2 


n-dat 
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De meme que pour le chargement de la sequence 1 , le lect ur 
re^it la commande et la renvoie vers la banque de donn^e. La banque de 
donnee recherche, dans le fichier de cette carte, les n-dat octets de donn^es 
non ex6cutables relatives k I'application P, numero de sequence 2. La 
banque de donndes diabore le message suivant qui est transmis k la carte 
via le lecteur : 



Carte C 


Appli P - Data- numero 


nombre 


n-dat octets de 




de sequence 2 


n-dat 


donn§es 



Le syst^me d'exploitation de la carte peut effectuer une operation 
10 preliminaire selon laquelle il v6rifie les codes C, P, le numero de sequence, 
et la valeur n-dat re^s. Si la verification est conforme, les octets sont Merits. 
Ensuite, le systeme d'exploitation calcuie et v^rifie la signature des 
donn^es. Si les deux valeurs sont 6gales, les donnees regues sont 
considerees comme identiques a celles prdcedemment dechargees par la 
15 carte : la seconde transaction peut done continuer. Le systeme d'exploitation 
met k jour le tableau TAB.APPLI en positionnant I'indicateur de chargement 
de Tapplication P/2 k « Charge » : 



Code 
application / 
Num6ro de 
sequence 


Informations relatives 
au programme executable et 
aux donnees de Tapplication 


informations relatives 
aux donnees evolutives 
des sequences notees « i » 


adresse 

de 
stockage 


nombre 
d'octets 


signature 


Chargd./ 
D6charg6 


adresse de 
stockage 


nombre 
d*octets 


signature 


Charge./ 
Oecharge 


P/1 


ADR- 
Cod-P 


n-cod 


SGN- 
cod-P 


Charge 


0 


n-dat 


0 


0 


P/2 


ADR- 
Cod-P 


n-cod 


SGr4- 
cod-P 


Charge 


ADR- 
Dat-P 


n-dat 


SGN-dat- 
P/2 


Charge 



tableau TAB APPL 



18 



20 La mise d jour du tableau TAB_APPLI 6tant termin^e, I syst6me 

d'exploitation lance I'application P qui va continuer la seconde transaction. 



40 

La seconde transaction 6tant termin6e, le programme de 
I'appllcation se termine par une instruction de retour au syst^me 
d'exploitation g§rant la m6moire virtuelle. Le systdme d'exploitation en 
ddduit que la sequence « 2 » est terminde ; la place mSmoIre peut alors &tre 
libdr^e. Pour cela, les emplacement, dans le tableau TAB_APPLI, de : 
« adresse de stockage », € signature » et I'indicateur de 
chargement/d§chargement sont mis k z^ro. Le tableau prend les valeurs 
suivantes : 



Code 
application / 
Num6ro de . 
sequence 


informations relatives 
au programnr>e executable et 
aux donn6es de rappiication 


informations relatives 
aux donnees evolutives 
des sequences notees « i 




.adresse„ 

de 
stockage 


nombre 
d'octets 


signature 


Charg6./ 
Dtehargd 


adresse de 
stockage 


nombre 
d'octets 


signature 


Charge./ 
Oecharge 


P/1 


ADR- 
Cod-P 


n-cod 


SGN- 
cod-P 


Charge 


0 


n-dat 


0 


0 


P/2 


ADR- 
Cod-P 


n-cod 


SGN- 
cod-P 


Charge 


0 


n-dat 


0 


0 



tableau TAB APPL1 19 



A ce stade, le systdme d'exploitation de la carte peut effacer 
entidrement une ligne du tableau TAB_APPLI. La gestion des lignes du 
tableau TAB_APPLI s'effectue alors dynamiquement en fonction des 
besoins. 

Une autre m§thode statique pour g6rer le tableau est de decider 
une fois pour toutes le nombre de sequences maximum ex6cutables pour 
une application : soit « s » ce nombre. « s » est alors transmis lors de la 
commande de chargement initial d'application : le syst6me d'exploitation 
reserve dans le tableau TAB_APPLI la place correspondant a ces « s » 
s6quences. Prenons par exemple pour s la valeur 2. 
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La commande de chargement de I'application K possdde ies 
valeurs suivantes : 



Ordre de Chargement 


Carte C 


AppliK 


nombre n 


s=2 








n-cod 


n-dat 





5 



Cette commande diff^re de celle d§crite pr^cddemment en ce qu'elle inclut 
une cinqui^me case definissant la valeur du paramdtre s. On notera qu'ici la 
commande specifie le nombre n-cod d*octets relatifs d I'application et 
envoyes par la commande, et le nombre n-dat d'octets relatifs d cheque 
10 sequence future et reserves d cet usage. En variante. le nombre n-dat 
d'octets peut ne pas 6tre transmis a ce stade, mais foumi plus tard au 
systeme d'exploitation de la carte par rapplication qui y est chargSe. 

A la suite de cette commande, le systeme d'exploitation met d jour 
15 le tableau TAB APPLI avec Ies valeurs suivantes : 



Code 
application / 
Num^ro de 
sequence 


Informations relatives 
au programme executable et 
aux donn^es de I'application 


informations relatives 
aux donnees evolutives 
des sequences notees € i » 


adresse 

de 
stockage 


nombre 
d'octets 


signature 


Charge./ 
Oecharge 


adresse de 
stockage 


nombre 
d'octets 


signature 


Charge./ 
oecharge 


K/l 


ADR- 
Cod-K 


n-cod 


SGN- 
cod-K 


Charge 


0 


n-dat 


0 


0 


K/2 


ADR- 
Cod-K 


n-cod 


SGN- 
cod-K 


Charge 


0 


n-dat 


0 


0 


tableau 1 


FAB APPL 


20 



20 L'application K peut maintenant &tre ex§cut§e : deux sequences 

sent possibles. 
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La carte peut parfaltement contenir de fa^on virtuelle plusieurs 
applications dotees chacune de plusieurs sequences. Par exemple, void 
une configuration particulidre du tableau TAB_APPLI : 



Code 

appiicauon / 


Informations relatives 
au programme executable et 
aux donn^es de I'application 


aux donnees 
des sequences 


reiaiivea 
evolutives 
notees c i 


» 


.Num6ro de 
sequence 


adresse 

de 
stockage 


nombre 
d'octets 


signature 


Charg67 
O^hargd 


adresse de 
stockage 


nombre 
d'octets 


signature 


Charge./ 
Decharge 


K/1 


Cod-K 


k-cod 


SGN- 
cod-K 


D6charg6 


0 


k-dat 


0 


0 


K/2 


ADR- 
Cod-K 


k-cod 


SGN- 
cod-K 


D6chdrg6 


/VDR- 
Dat-K/2 


k-dat 


SGN-dat- 
K/2 




K/1 


ADR- 
Cod-K 


k-cod 


SGN- 
cod-K 


D6charg6 


/»iDR- 
Dat-K/3 


k-dat 


SGrO^at- 
K/3 


Charge 


J/1 


ADR- 
Cod-J 


j-cod 


SGN- 
cod^ 


Charge 


/VDR- 
Dat-J/1 


i-dat 


SGN-dat- 
J/1 




J/2 


/UDR- 
Cod^ 


j-cod 


SGN- 
cod-J 


Charge 


ADR- 
Dat-J/2 


j-dat 


SGN-dat- 
J/2 





tableau TAB APPLI 21 



Correspondant d cet exemple. la carte poss6de virtuellement 
deux applications not§es : K et J. Le programme ex6cutable de I'application 

10 K n'est pas en zone de chargement ; trois s6quences de cette application. 
not6es 1,2 et 3. peuvent s'ex6cuter en m&me temps. La premiere sequence 
est termin6e. les deux autres sont en cours d'ex6cution. La s6quence 2 est 
d6charg6e : il faudra done la recharger pour la terminer. De plus, pour 
terminer les sequences 2 et 3. il faudra recharger le programme executable 

15 et les donnSes de I'application K. 

Le programme executable de Tapplication J est en zone d 
chargement ; cette application peut ex6cuter en mSme temps deux 
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s6qu8nces, not§ s 1 et 2, qui sont en cxjurs d'execution. La sequence 2 est 
d6charg§e : il faudra la recharger pour la terminer. 

Oe cat exemple, on voit apparaitre la necessity de bien gerer la 
5 place mdmoire disponible. II faut occuper le plus possible ia zone de 
chargement et ainsi 6viter le plus souvent les commandes de O^chargement 
et Rechargement 

Bien 6videmment, ramelioration consistant a chiffrer les donn^es, 
10 en plus de les signer, lors du dechargement et a les dechiffrer lors du 
chargement/rechargement. peut s'appliquer a cette troisieme amelioration. 

Une amelioration de la procedure de chargement initial d'une 
application en carte consiste d introduire dans la carte une signature des 
15 informations applicatives calculee h partir d'une cid de foumisseur 
d'application. Cette signature permet de s'assurer de rintegritd des 
informations applicatives et d'authentifier Torigine de ces donnees 
applicatives. 

20 Le chargement initial selon ('amelioration consiste k presenter la 

carte au foumisseur d'application. 11 est conseilie d'effectuer cette operation 
dans les locaux du foumisseur d'application. Ce dernier introduit dans la 
carte sa cle de foumisseur, la signature des informations applicatives. et le 
code de Tapplication, « K » par exemple. Un porteur de la carte effectue une 

25 demande de chargement initial de Tapplication K. Cette demande, qui a ete 
d6crite pr6c6demment. peut fetre faite a son domicile. Une mSthode pour 
effectuer de fa9on s6curis6e le chargement initial d'une application est 
d§crite dans le document FR-A-2.748.134. 

30 Selon une variante de realisation de invention , les applications 

stocke s en carte n sont pas dSchargees dans une banque de donndes 
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distante. au travers d'un reseau : c'est le lecteur 20 de la figure 2 qui regoit 
et stocke ces applications ; il poss^de alors k eel effet une m6moire 
programmable non volatile dans laquelle sont stock6es les applications. Les 
commandGs de chargement et de d6chargement sont inchang6es. Cette 
variante est int6ressante lorsque la carte est introduite toujours dans le 
mfeme lecteur. par exemple un lecteur situ6 au domicile du porteur de carte. 



Une autre variante de r6alisation de I'invention utilise le lecteur de 
carte 40 et la carte ^ puce 41 de la figure 4. dont les 6l6ments communs 

10 avec ceux de la figure 2 portent les mfemes references. La carte 41 se 
distingue de celle 21 de la figure 2 en ce qu'elle porte une piste optique 42. 
par exemple une piste 6criture et lecture par rayon laseir. Quant au lecteur 
de carte 40. il se distingue de celui 20 en ce qu'il comporte un lecteur de 
piste optique 43. apte ^ lire et 6crire des infomDations sur la piste optique 42, 

1 5 reli6 au microprocesseur 2 et aux m^moires 3,4. 

Selon I'invention , la piste optique 42 est utilis6e en tant que 
banque de donn6es . au lieu de celles distantes 23 d 25 de la figure 1. En 
pratique, lors du d6chargement d'une application depuis la carte 41 . la carte 
20 transmet la commande de d6chargement au lecteur de carte 40. Le lecteur 
de piste 43 recoil les informations de Tapplication et les 6crit sur la piste 
optique 42. Lors d'une commande de rechargement. le lecteur de carte 
active le lecteur de piste 43 pour qu'il pr6t6ve sur la piste optique 42 les 
informations de Tapplication : le lecteur de carte transmet ensuite ces 

25 informations au microprocesseur 9 de la carte pour que celui-ci les stocke 
dans la zone de chargement. Les commandes de chargement et de 
d§chargement sont toutefois inchang6es. 

En variante. la piste optique est remplac6e par un autre support d 
stockage d masse, par exemple une piste magn6tique. 

30 Dans les x mples de realisation pr6c6dents. on a consid6r6 qu 

I'application 6tait chargee et ex6cut6e dans la cart 21 de la figur 2. ou 
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dans le module correspondant 15 de la figure 3. Selon une autr variante de 
r6a!isation moins pr^f§r6e de I'invention, c'est dans le tenninal 20 de la 
figure 2, ou dans la partie du terminal 22 de la figure 3 coop^rant avec le 
module 15 que I'applicatlon est charg6e et executee. plus precls§ment dans 
la m^moire RAM de celui-ci. Le terminal poss^dera aussi une memoire 
programmable non volatile pour stocker I'appllcation de fagon durable. 
Toutefols, avant tout ddchargement de i'appllcation vers le r^seau. le 
terminal transmettra I'appllcation d la carte 21 (ou au module 15 
con-espondant) de fa^on que celle-ci calcule la signature des informations 
de I'applicatlon ; de m&me. avanl toute execution de I'application dans le 
terminal apr6s son rechargement depuis le reseau. le terminal effectuera la 
m§me procedure pour qu'une nouvelle signature de I'application soit 
caicul6e par la carte et compar^e d la pr6c6dente : la carte transmettra au 
terminal un resuttat de cette comparaison et, seulement en cas d'identit^. le 
terminal exdcutera rapplication rechargde. 

Dans les exemples de r6alisation pr6cedents, on a d6crit un 
d§chargement d'applications depuis un dispositif de traitement de 
I'information vers rext6rieur de celui-ci : dans le cas de la figure 2, la carte 
21 effectuait un d6chargement vers le lecteur 20 ou les banques de donnSes 
23-25 de la figure 1 ; dans le cas de la figure 4. le dispositif de traitement de 
I'information constituS par le microprocesseur 9 et ses m^moires 10,14 
effectuait un dechargement vers la piste optique 42. Selon une autre 
variante de realisation de I'invention. un dispositif de traitement de 
{'information effectue un dechargement entre piusleurs m^moires de ce 
dispositif. Par exemple, ce dispositif de traitement de I'information est 
constituS par ia carte 21 de la figure 2 et le microprocesseur 9 dScharge une 
application depuis sa m6moire RAM 14 vers sa m6moire non volatile 10. 

Par exemple, plusi urs applications K, J sont stock6es dans la 
m6moire non volatile 10. Tout d'abord, I'application K st ex6cut6 . A cette 
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occasion, des informations de travail itk relatives a rapplication K sont 
traitdes en memoirs RAM, tandis qu'un programme de {'application K reste 
en m^moire non volatile 10. Ces informations de travail comprennent 
notamment : 

5 - des variables de travail temporaires, intervenant dans des calculs ; 

- des variables de contexte, permettant d la carte de reprendre 
ultdrieurement une execution d'application interrompue ; 

- des sous-programmes. 

A un moment donnd, la carte doit executor Tautre application J et, pour cela, 
10 charger des informations de travail Iti dans la mdmoire RAM. Si la carte 
constate que Tespace libra dans la memoire RAM est insuffisant pour 
recevoir les informations de travail Itj . elle decide de stopper TexScution de 
{'application K et de decharger les informations de travail itk de i'application 
K dans sa m§moire non volatile 10. Puis elle execute rapplication J en 
15 chargeant les informations de travail Itj associ^es en memoire RAM. Aprds 
execution de rapplication J, la carte reprend I'ex^^cution de rapplication K, h 
I'endroit ou celle-ci a 6t§ interrompue, en chargeant k nouveau les 
informations de travail It^ en m§moire RAM. 

20 Dans cette derniere variante de I'invention, les commandes de 

chargement et de dechargement ne sont pas utilisees, puisque le dispositif 
de traitement de Tinformation concerne n'a pas k avertir un dispositif externa 
pour effectuer les operations de chargement et dechargement de ses 
m6moires. II poss^de encore un tableau TAB_APPLI. mais celui-ci est 

25 simplifid par rapport au tableau 2 pr^citd : le paramdtre « signature des 
informations » est supprim6. En effet. les informations ne sortant pas du 
dispositif de traitement de Tinformation, elles ne risquent pas d'&tre alt6r6es 
durant leur dechargement. 
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REVENDICATIONS 

1 . Dispositff de traitement de rinformation comprenant des moyens de 
traitement de rinformation (9) et des moyens de memorisation de {'information 

5 principaux (10,14). caraderisd en ce que les moyens de traitement 
comprennent : 

- des moyens-pour dStecter, au cours du fonctionnement du dispositit 
de traitement de rinformation, que les moyens de memorisation principaux 
(10,14) contiennent une quantity d'informations telle qu'un stockage 

10 suppl^mentaire d'un ensemble donne d'informations d stocker (J) n'est pas 
possible ; 

- des moyens pour sdlectionner, dans les moyens de memorisation 
principaux, un ensemble d'informations d decharger (K), dont le 
d^chargement peut liberer dans les moyens de memorisation principaux un 

15 espace sufFisant pour autoriser le stockage dudit ensemble d'informations d 
stocker ; 

- des moyens pour decharger I'ensembte d'informations d decharger 
(K) dans des moyens de memorisation secondaires (23 ^ 25 ; 42 ; 53) , dans 
le cas ou lesdits moyens de memorisation secondaires ne contiennent pas 

20 ledit ensemble d'informations e decharger ; et 

- des moyens pour stocker dans les moyens de memorisation 
principaux (10,14) I'ensemble d'informations e stocker (J). 

2. Dispositif selon la revendication 1. qui comprend un tableau de 
25 chargement (TAB_APPLI) stocke dans les moyens de memorisation 

principaux et incluant un indicateur de stockage indiquant. pour au moins un 
ensemble d'informations , si celui-ci est stocke ou non dans les moyens de 
memorisation principaux. de sorte que , lorsque les moyens de traitement (9) 
doivent avoir acces audit ensemble d'informations , ils consultent ledit 
30 indicateur de stockage : et 
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- dans un premier cas ou I'indicateur de stockage indique que 
l ensemble d'informations est stock6 , les moyens de traitement acc6dent d 
celui-ci ; ou 

- dans un second cas ou Tindicateur de stockage indique que 
5 I'ensemble d'informations n'est pas stock6 , les moyens de traitement 

envoient aux moyens de memorisation secondaires (23 d 25 ; 42 ; 53) une 
commande de chargement de cet ensemble d'informations. 

3. Dispositif selon la revendication 2. dans lequel I'indicateur de 
10 stockage comporte un 6tat «charg6» indiquant que I'ensemble 

d'informations correspondent a 6t6 charg6 dans le dispositif de traitement de 
I information d partir des moyens de memorisation secondaires (23 ^ 25 ; 42 ; 
53). et un 6tat « d6charg6 » indiquant que I'ensemble d'informations a 6t6 
decharge par le dispositif de traitement de I'information dans les moyens de 
15 memorisation secondaires. 

4. Dispositif selon la revendication 1, qui comprend un tableau de 
chargement (TAB_APPLI) stocke dans les moyens de memorisation 
principaux (10,14) et incluant un indicateur de modification indiquant, pour au 

20 moins un ensemble d'infomiations dont une premiere version a et6 chargee 
dans le dispositif de traitement de I'infomiation e partir des moyens de 
memorisation secondaires (23 e 25 ; 42 ; 53). si cette premiere version a ete 
modifiee dans le dispositif de traitement de I'information. 

25 5. Dispositif selon la revendication 1 . qui stocke au moins un ensemble 

d'informations en deux parties, e savoir un sous-ensemble d'informations 
d'application (p-cod) contenant un programme et des donnees generates de 
fonctionnement d'une application, et un sous-ensemble d'informations de 
sequence (p-dat) contenant des donnees particuli6res definissant une 

30 session particuli6re de fonctionnement de rapplication , t qui comprend des 
moyens pour d6tecter que plusieurs ensembles d'informations possedent un 
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m6me sous-ensemble d'infomnations d'application (F>-cod) et des sous- 
ensembles d'infonnations de sequence respectifs diff^rentis (p-dat), de sorte 
qu'ii ne stocke dans les moyens de memorisation principaux (10,14) qu'une 
fois ledit sous-ensemble d'infomiations d'application et qu'il associe k celui-ci 
5 chacun desdits sous^nsembies d'infomnations de sequence. 

6. Dispositif selon la revendication 5, qui comprend : 

- des moyens pour dStecter, au cours de son fonctionnement, que les 
moyens de memorisation principaux (10,14) contiennent une quantity 

10 d'tnformations telle que le stockage suppldmentaire d'un sous-ensemble 
d'informations de sequence (p-dat) k stocker , a$soci§ h un sous-ensemble 
d'informations d'application (p-cod) dejd stocks, n'est pas possible ; 

- des moyens pour seiectionner, dans les moyens de memorisation 
principaux, un sous-ensemble d'informations de sequence d decharger, 

15 associe au mdme sous-ensemble d'infomnations d'application , dont le 
dechargement peut liberer dans les moyens de memorisation principaux un 
espace sufTisant pour autoriser le stockage dudit sous-ensemble 
d'informations de sequence k stocker ; 

- des moyens pour decharger ce sous-ensemble dans lesdits moyens 
20 de memorisation secondaires (23 a 25 ; 42 ; 53). dans le cas ou lesdits 

moyens de memorisation secondaires ne contiennent pas ledit sous- 
ensembte d'infomnations de sequence a decharger ; et 

- des moyens pour stocker dans les moyens de memorisation 
principaux le sous-ensemble d'informations de sequence k stocker. 

25 

7. Dispositif selon la revendication 5, qui comprend un tableau de 
chargement (TAB_APPLI) stocke dans les moyens de memorisation 
principaux et incluant, pour cheque sous-ensemble d'informations 
d'application stocke, un nombre maximum (s) de sequences associees, 

30 pouvant etre stockees dans I s moyens de memorisation principaux. 
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8. Dispositif selon la revendication 1, qui comprend des moyens pour 
recharger dans les moyens de memorisation principaux (10,14) un ensemble 
d'informations pr6alablement d6charg6 dans les moyens de memorisation 
secondaires (23 d 25 ; 42 ; 53). 

9. Dispositif selon la revendication 8, qui comprend un tableau de 
chargement (TAB_APPLI) stock6 dans les moyens de memorisation 
principaux (10,14) et incluant, pour au moins un ensemble d'informations (K) 
traite par le dispositif, une premiere signature (SGN-K) de cet ensemble 
d'informations calcuiee par les moyens de traitement (9) avant le 
dechargement 6ventuel de I'ensemble d' information, avec une cl6 de 
signature (SWAP) stockee dans les moyens de memorisation principaux, les 
moyens de traitement etant agences pour calculer une seconde signature de 
rensemblo d'informations recharge, pour comparer cette seconde signature 
avec la premiere, pour valider le rechargement de I'ensemble d'informations 
dans le cas oCi les deux signatures sont identiques. et pour invalider le 
rechargement de I'ensemble d'informations dans le cas ou les deux 
signatures sont differentes. 

10. Precede de stockage d'informations dans un dispositif de 
traitement de I'information comprenant des moyens de traitement de 
I'information (9) et des moyens de memorisation de I'information principaux 
(10,14) , et dans des moyens de memorisation secondaires associes (23 ^ 25 
; 42 ; 53), caracteris6 en ce qu'il comprend les etapes consistant e : 

- detecter, au cours du fonctionnement du dispositif de traitement de 
I'information, que les moyens de memorisation principaux contiennent une 
quantite d'infonnations telle qu'un stockage suppl6mentaire d'un ensemble 
donne d'informations h stocker (J) n'est pas possible ; 

- seiectionner, dans les moyens de memorisation principaux, un 
ensemble d'infomiations d d6charger (K), dont le d6chargement peut Iib6rer 
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dans I s moyens de memorisation princlpaux un espace suffisant pour 
autoris r le stockage dudit ensemble d'informations a stacker ; 

- decharger I'ensemble d'informations ^ decharger (K) dans les 
moyens de memorisation secondaires. dans ie cas ou lesdits moyens de 

5 memorisation secondaires (23 ^ 25 ; 42 ; 53) ne contiennent pas (edit 
ensemble d'informations d decharger ; et 

". stocker dans les rnoyens de memorisation princifsaux (10,14) 
I'ensemble d'informations e stocker (J). 

^0 H- Precede selon la revendication 10, qui comprend les etapes 

consistant a : 

- detecter, au cours du fonctionnement du dispositif de traitement de 
I'lnformation, que les moyens de memorisation princlpaux (10,14) contiennent 
une quantite d'informations telle qu'un stockage suppl6mentaire d'un 

15 ensemble donn6 d'informations prealablement decharge est possible ; 

- recharger dans les moyens de memorisation principaux ledit 
ensemble d'informations decharge. 

12. Precede selon la revendication 10, qui comprend les etapes 
20 consistant a : 

- detecter, au cours du fonctionnement du dispositif de traitement de 
rinformation. que les moyens de memorisation prindpaux (10,14) contiennent 
une quantite d'informations telle qu'un stockage suppiementaire d'un 
ensemble donn6 d'informations prealablement decharge (K) n'est pas 

25 possible; 

- seiectionner, dans les moyens de memorisation principaux, un 
ensemble d'informations e decharger (J), dont le dechargement peut liberer 
dans les moyens de memorisation principaux un espace suffisant pour 
autoriser le stockage dudit ensemble d'informations prealablement decharge ; 

30 - decharger I'ensemble d'informations a decharger (J) dans les moyens 

de memorisation secondaires (23 e 25 ; 42 ; 53). dans I cas ou lesdits 
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moyens de memorisation secondaires ne contiennent pas ledit ensembi 
d'informations d ddcharger ; et 

- recharger dans les moyens de memorisation principaux ledit 
ensemble d'informations pr6alablement dScharge (K). 

13. Proc6d6 selon la revendication 10, dans lequel lesdits moyens de 
memorisation secondaires comprennent une banque de donn6es (23-25)^ 
distante du dispositif de traitement de ('information et reli6e e celui-ci par un 
reseau de transmission de donnSes (26). 

14. Procede selon la revendication 10, dans lequel lesdits moyens de 
memorisation secondaires appartiennent d un second dispositif de 
traitement de I'infomiation (20) coop6rant avec ledit dispositif de traitement 
de I'information (21). 

15. Precede selon la revendication 10. dans lequel lesdits moyens de 
memorisation secondaires (42;53) appartiennent audit dispositif de 
traitement de I'information. 
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